專案就像一場長跑，跑到終點才發現方向錯了，那才是真正的災難。印象很深的是幾年前的一個專案，文件寫得厚厚一疊，需求會議開了十幾場，大家都自以為「彼此理解一致」。然而，直到我們第一次做 Demo，客戶看到系統畫面時脫口而出一句：「這不是我們要的。」

從那次經驗開始，我徹底改變了對 Demo 的看法。它不是「炫耀成果」的場合，而是專案過程中最重要的「校正點」。

為何要 Demo

Demo 的價值在於─對齊認知：

• 文件寫得再詳細，文字也難免模糊；
• 程式碼再漂亮，非技術角色依然看不懂；
• 會議再多，想像依舊會南轅北轍。

Demo 讓大家把「腦中的假設」化為「眼前的具體操作」，這比任何紙上文字都更有說服力。對我而言，Demo 的核心目的就是：提早揭露錯誤，避免專案走到死胡同。

Demo 是給誰看的

不同角色，看 Demo 的角度完全不同：

• 商業單位／產品經理：關心功能是否解決了商業需求，使用流程是否合理。
• 管理階層：想知道專案投入的資源是否值得，能否創造實際價值。
• 工程團隊：透過 Demo 確認模組間是否能順利協作，避免「各自完成卻無法整合」的尷尬。
• 使用者／客戶：最直白的檢驗者，他們的反應往往決定專案成敗。

因此，Demo 不是單一套路，而是針對不同觀眾調整重點。

如何做好 Demo

一場成功的 Demo，必須有設計與準備：

1. 鋪陳場景：先交代「這個功能要解決什麼問題」，讓聽眾有代入感。
2. 簡單聚焦：專注展示「核心價值」，而非把所有小細節一口氣攤開。
3. 互動留白：預留讓觀眾發問、試用的時間，藉此確認理解是否一致。
4. 備援方案：Demo 最怕臨場出狀況，因此要有錄影、測試資料或第二環境，避免當場冷場。

總結

那次「不是我們要的」的經驗，雖然痛苦，但卻讓我們在專案早期就踩到坑，得以及時修正。也正因如此，專案最後才能交付符合需求的成果。從那之後，我總是提醒自己：不要害怕 Demo，因為它是檢驗真相、避免災難的最好時機。